Conversation
There was a problem hiding this comment.
Thanks for putting this together @casio
I think having program.importRoot and config.root is okay. It allows us to release this change as a patch and seeing as you've set importRoot to take precedence over root that matches the expected behaviour.
I agree that output should be left alone.
bin/suitcss
Outdated
| if (input) { | ||
| var resolvedInput = importRoot ? resolve(importRoot, input) : resolve(input); | ||
| if (!exists(resolvedInput)) logger.fatal('not found', resolvedInput); | ||
| else input = resolvedInput; |
There was a problem hiding this comment.
Could we use braces here for the if/else? Just matches it up with everything else
| @@ -59,15 +59,15 @@ describe('cli', function() { | |||
| }); | |||
|
|
|||
| it('should output stylelint warnings', function(done) { | |||
There was a problem hiding this comment.
these are testing other feature, would you mind creating a suite only to test the importRoot thing instead of mixing tests up?
There was a problem hiding this comment.
hm, test/cli.js currently is really more of an integration test suite, no?
so imho its ok to test all i/o stuff there.
it would probably be cleaner to eg remove the -i options out of unrelated cases, though
There was a problem hiding this comment.
I mean a nested describe in test/cli.js with the importRoot relevant tests.
The point is testing imports indirectly i.e. by tweaking other tests to cover some use cases it is not optimal.
|
should we also fix this part? |
df11fdf to
7431055
Compare
|
@giuseppeg Do you mean normalising it so it always refers to |
|
@simonsmith we said that CLI flags should always override config file options, in this case
Basically yes |
|
Maybe get this merged and we can address the other issue separately. Do we just need to make those test case changes? |
Yeah. |
|
Might be easier as it can be done in parallel. Then I think we're set to release a patch |
|
hey guys! sorry, have been a bit busy & thus silent. please ping me if you'd like me to add more changes or squash the prev commits. |
|
@casio Not a problem, we're all busy at times :) I think if you could address the feedback about grouping the tests in a single |
7431055 to
2dfbf78
Compare
|
so I just put the importRoot related test in its own nested describe block, as @giuseppeg suggested. it might be a good idea to, in one of the next steps, switch tests unrelated to importRoot to not make use if |
|
@casio Yes, agreed. We can just give the full path to the fixtures which hilariously it seems like I had done even with |
2dfbf78 to
98ddec0
Compare
|
@simonsmith haha : ) fyi seeing appveyor bark, I just pushed an update. strangely the local lint task didnt catch that( |
|
I think this looks good to merge. @giuseppeg ? |
|
@casio were the other tests failing after your changes? I think that |
|
@giuseppeg yes, they were. actually with how this is currently implemented, the name and you're right, I guess: basically these are two different things - a root for the input(=entry) file and another one to resolve maybe it'd even be beneficial to revisit the concept/scope of how these things should work: ie. should it be rather import roots(plural), do we need a separate base path to resolve input and output, etc. |
|
I don't see any failing tests? |
|
I think @giuseppeg meant tests that read like Theses were failing with the new behavior since the cli tried to read |
|
Yea I can take a look at the issue again and the PR, I am just hopping on and off and I haven't been able to read it carefully because I am busy – sorry about that :) |
|
Interesting, I see what you guys mean. Yeah it should relate directly to the postcss import root option. |
|
Took a quick look, this is a non-issue because |
|
So are we saying the issue in #64 is expected? Should the user be prepending the correct path to the input file? |
|
It has always been like that. Ideally the |
|
I see. I guess that does correctly mimic how it would with |
|
So it looks like this is PR is not worth merging then? I fear we may have led you down a wrong path @casio. My apologies if so D: |
|
@simonsmith haha, no worries. was worth the ride : ) |
|
thank you for your time @casio! Sorry for the inconvenience. |
currently this fixes #64
however, there's still ambiguity with the CLI flag
importRootandrootcoming from config files.importRoottakes precedence now, but I guess both should just be namedroot.also, we might consider
outputto be resolved around the same root. having thought about that a little more, I think we actually should not - most of the time the output will go into some arbitrarily located dist folder, I guess.thoughts?